Summary

Reverts the SCR-68 Stripe→Hyperline migration. Restores the pre-migration Stripe billing implementation in full (`bins/scrapix-api/src/stripe.rs` + the original console billing page with Stripe Elements).

Reverted commits (in reverse merge order):

• `5c33bde` — PR feat(billing): auto-seed Hyperline products on boot when HYPERLINE_AUTO_SEED=1 #20 `feat(billing): auto-seed Hyperline products on boot`
• `20bf932` — PR fix(billing): auto-link accounts to Hyperline customer #19 `fix(billing): auto-link accounts to Hyperline customer`
• `3a94103` — PR SCR-68: migrate billing from Stripe to Hyperline #6 `SCR-68: migrate billing from Stripe to Hyperline` (the big one — 42 files, +3913/-2610)

Plus one fix on top: `ca08a02` re-adds an idempotent `ALTER TABLE accounts ADD COLUMN IF NOT EXISTS stripe_customer_id` to `deploy/postgres/init.sql`. SCR-68 explicitly dropped this column; the revert restored the inline `CREATE TABLE` definition but *not* an idempotent migration to re-add it on existing DBs. Without this, the first `/account/billing` request would 500 because `stripe.rs` heavily queries the column.

Why revert

The Hyperline integration didn't fit. Going back to Stripe is the path of least surprise — the code on this branch was working in production before SCR-68 was merged.

User confirmed: zero paying customers at time of revert, so the destructive rollback is data-safe.

Schema state after deploy

The reverted `init.sql` runs on every API boot via `sqlx::raw_sql(...)`. After this PR deploys:

• `accounts.stripe_customer_id` → re-added (was dropped by SCR-68).
• `accounts.stripe_default_payment_method_id` → re-added (existing idempotent block, was dropped by SCR-68).
• `accounts.auto_topup_*` → re-added (existing idempotent block, were dropped by SCR-68).
• `accounts.hyperline_customer_id`, `accounts.hyperline_wallet_id`, `accounts.payment_method_status` → left in place as orphan columns. No deploy-blocking issue (Stripe code doesn't query them). Can be dropped in a cleanup PR.
• `hyperline_events_outbox`, `hyperline_webhook_log` → left in place as orphan tables. Same — clean up later.
• `transactions.type` CHECK constraint → existing prod has the widened (Hyperline) version, reverted `init.sql` ships the narrow version inline in `CREATE TABLE IF NOT EXISTS` which is a no-op on existing tables. Wider CHECK on prod is permissive — doesn't block the reverted code from inserting the original 6 transaction types. Can be re-narrowed in cleanup.

Deploy plan

1. Merge this PR.
2. Fly.io rolling deploy — new API instance boots → applies `init.sql` → re-adds missing Stripe columns idempotently.
3. Once healthy: remove `HYPERLINE_` env vars from Fly.io. Verify `STRIPE_` vars are still set (they were never removed).
4. Smoke test: load `/dashboard/billing`, add a test card, buy 1k credits, verify ledger.

Follow-up cleanup PR (not in this one)

• `DROP TABLE hyperline_events_outbox`
• `DROP TABLE hyperline_webhook_log`
• `ALTER TABLE accounts DROP COLUMN IF EXISTS hyperline_customer_id, hyperline_wallet_id, payment_method_status`
• Re-narrow `transactions.type` CHECK (after confirming no Hyperline-typed rows exist).

Verification

• `cargo check --workspace` passes (cold compile, exit 0).
• Zero remaining `hyperline` references in source: `grep -ri hyperline --include='.rs' --include='.ts' --include='.tsx' --include='.sql' --include='*.mdx'` is empty.
• Console TypeScript not re-verified locally (no node_modules) — restored billing page is identical to pre-SCR-68 known-good state; CI typecheck will confirm.

Test plan

• CI green
• Deploy to staging, hit `/account/billing`, verify 200 (not 500)
• Add card → `payment_methods` populated
• Buy 1k credits → `transactions` shows `manual_topup`, balance updates
• Auto top-up toggle works
• Stripe webhook delivers `payment_intent.succeeded` and credits land in ledger